COMMENT ⊗   VALID 00002 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	. SSSEC(Alternatives to the Agenda Scheme)
C00007 ENDMK
C⊗;
. SSSEC(Alternatives to the Agenda Scheme)

<<Should "Alterns-to-agenda" be moved elsewhere?>

Below  is a digression, explaining  why the agenda  scheme was chosen
instead of some more conventional  way of managing a large  heuristic
search.

.BN

λλ Why not  let a "node" be  a concept, instead of the  artifice of a
facet/concept/reasons  structure?  In a  standard heuristic search, a
particular operation is applied  to a particular node, and  new nodes
result.   To fill in all  the facets of a concept  would take several
cpu minutes.  This is simply too long to be practical, and it is  not
very desirable: we don't want to specialize  and generalize every new
concept!

λλ  We could  let the  individual heuristic  rules be  considered our
knowledge  sources. But  the  most  interesting  effects  occur  when
several heuristics  combine to support  some task. Also, the  unit of
action  ("apply a certain heuristic")  would then be  too quick for a
human user to follow.

λλ We could  consider that we have  one central program, but  that it
can ⊗4↓_recurse_↓⊗* whenever a  better task becomes evident.  One can
then  imagine  that  the  control-stack  would  contain  a  list   of
interrupted  tasks, getting  more  and  more worthwhile  (better  and
better reasons) as we proceed toward the current moment.  The current
task can't be interrupted, except for the sake of performing  an even
⊗4more⊗* interesting task.  If  the current task finishes, the normal
recursion  process will take  us back to  finish the last  task.  But
recent discoveries may dramatically effect the  worthwhileness of the
activities on the  control stack; how could we  reorder them?  Within
the standard function-calling scheme, this can't be done.

λλ It sounds  like we might  need to have  a ⊗4↓_process_↓⊗*  scheme,
involving many active tasks, which can go to  sleep and wake up under
certain conditions.   But each task only  takes about 10 cpu seconds.
Is it really worth it to worry about interrupting one of these tasks,
once it's started?  Is it worth using a hundred memory cells to store
the state  of process that would only use up 5 more cpu seconds if we
let it  wake up  and continue?   What  if we  have to  keep around  a
thousand partially-complete tasks?

λλ Most of the tasks we have hanging around are fairly independent of
each  other,   so  perhaps   we  could   exploit  the   power  of   a
⊗4↓_multi-processor_↓⊗*.  But we have thousands  of little tasks, and
they spawn new ones. A fixed number of processors can provide at best
a constant  speed-up  factor.   Also,  the results  of  experiment...
indicate  that  a  very  important   mechanism  is  the  one  whereby
highly-rated  new tasks  get suggested  dynamically, while  the current
task is  executing.   So the  gain  in speed  would only  be a  small
factor.

.END